home *** CD-ROM | disk | FTP | other *** search
/ The Very Best of Atari Inside / The Very Best of Atari Inside 1.iso / mint / mintman / mint.doc < prev    next >
Text File  |  1991-11-02  |  29KB  |  577 lines

  1. MiNT is Not TOS: A Multitasking Operating System Extension for the Atari ST
  2.  
  3. Copyright 1990,1991 Eric R. Smith. All rights reserved. See the file COPYING
  4. for conditions of redistribution.
  5.  
  6. WARNING: This program does some very low level things to your computer.
  7. MiNT works well on my machine, and I trust my data to it. But
  8. then, I make regular backups, so even if a horrible bug in MiNT that
  9. I haven't found yet trashes my hard drive, I won't lose much. You'll
  10. have to decide for yourself about trusting your data to MiNT. I would
  11. certainly recommend regular backups in any event.
  12.  
  13. MiNT COMES WITH ABSOLUTELY NO WARRANTY, NOR WILL I BE LIABLE FOR ANY
  14. DAMAGES INCURRED FROM THE USE OF IT. USE ENTIRELY AT YOUR OWN RISK!!!
  15.  
  16. Introduction
  17.  
  18. MiNT is an extension of (and eventually, I hope, a replacement for) TOS.
  19. It provides extra services such as multitasking and pipes. If you don't
  20. know what those terms mean, MiNT is probably not for you -- at this stage,
  21. MiNT is still very incomplete and should be regarded as "experimental".
  22.  
  23. MiNT will run a great number of ("most", I hope) TOS programs, including
  24. GEM. As the name says, though, MiNT is not TOS, so it can't be expected to
  25. run all TOS programs, or even all well-behaved TOS programs (although I hope
  26. that it will run "almost all" of the latter!). There are two classes of
  27. incompatibilities with TOS: bugs and features. Bugs are undoubtedly
  28. present; if you find any please report them to me. There are also some
  29. features of MiNT that may cause incompatibilites. Most of these are listed
  30. in the accompanying "features" file. 
  31.  
  32. MiNT tries to emulate TOS 1.4 very closely. If you have TOS 1.0 or 1.2,
  33. you may think you can use MiNT instead of buying TOS 1.4. This isn't really
  34. a very good idea, because MiNT calls TOS, and so having the newer version
  35. of TOS will really speed things up. Besides, the GEM that comes with TOS 1.4
  36. is a lot better than the old GEM.
  37.  
  38.  
  39. Using MiNT
  40.  
  41. MiNT can be started from an AUTO folder, by setting it as a BOOT program
  42. on the desktop (TOS 1.4 or higher only) or by running it. I prefer the AUTO
  43. folder way myself.
  44.  
  45. If you put it in an AUTO folder, it should be the last thing in the folder
  46. (since any later programs in the folder will run only after MiNT is finished,
  47. and MiNT should never finish). MiNT will try to run a program called
  48. "init.prg" in the current directory  (which is the root directory if MiNT
  49. was started from an AUTO folder). If this program isn't found, MiNT will
  50. boot up GEM. You can change the name of the initial program to run
  51. via the "mint.cnf" file (see below).
  52.  
  53. Once MiNT is running, the computer should behave just as it does under TOS,
  54. except that some new drives (U, Q, V, and X) will be available, background
  55. processes can be started, and programs can use the new features of MiNT.
  56.  
  57. MiNT can be asked to provide a trace of the currently executing programs.
  58. Hitting CTRL-ALT-F1 increases the debugging level; hitting CTRL-ALT-F2
  59. decreases it, and hitting CTRL-ALT-F3 changes where the debugging output
  60. goes; pressing it once changes it from the screen to the printer, pressing
  61. it again changes it to the RS232 port, pressing a third time sends debugging
  62. output to the MIDI port. Pressing CTRL-ALT-F4 resets output to the screen.
  63. This feature was designed to aid in debugging MiNT itself, but can also be
  64. useful in finding problems with user programs. Debugging level 0 (the normal)
  65. prints messages only when something goes seriously wrong inside of MiNT itself. 
  66. Debugging level 1 prints a message when any system call fails. Debugging level
  67. 2 provides a (sickeningly) exhaustive trace of what's going on in the system.
  68.  
  69. CTRL-ALT-F5 shows what memory is being used in the system
  70. CTRL-ALT-F6 prints a list of all processes in the system
  71. CTRL-ALT-DEL provides a (warm) boot, as in TOS >= 1.4, and
  72. CTRL-ALT-SHIFT-DEL provides a cold boot.
  73.  
  74. Some other keys are recognized by MiNT if the process is doing I/O in
  75. "cooked" mode:
  76. ^C (CTRL-C): interrupt running program with signal SIGINT. This (usually)
  77.     will kill the process, unless it has made arrangements to catch it.
  78.     Note that ^C takes effect immediately under MiNT, whereas under TOS
  79.     it only takes effect when the process reads or writes.
  80. ^\: send a QUIT signal to a process; usually the same end result as ^C, but
  81.     it is guaranteed to kill a TOS program (only MiNT specific programs
  82.     know how to catch it). Use with caution.
  83. ^Z: suspend the current process
  84.  
  85. These keys do *not* have any effect on processes operating in "raw" mode,
  86. such as editors. However, you can force these to work even on such programs
  87. by holding down the ALT key as well, i.e. CTRL-ALT-Z will always suspend
  88. the process. You should use caution when doing this, since some programs
  89. will function incorrectly and/or lose data if interrupted when they
  90. aren't expecting it.
  91.  
  92.  
  93. The MiNT Configuration File
  94.  
  95. If MiNT finds a file called "mint.cnf" in the root directory of
  96. the disk, it will read some configuration information from it. This
  97. file is an ordinary ASCII text file; it can be created with any editor
  98. that will produce plain ASCII files (if you're using a fancy word
  99. processor, make sure you save the file as "plain ASCII text" or
  100. "unformatted text" or whatever).
  101.  
  102. The commands in mint.cnf are placed one per line, and may be of the following
  103. forms:
  104.  
  105. INIT=d:\foo\bar.prg
  106.     This specifies the drive and full path name to the program you
  107.     want MiNT to run at boot up time. The default is ".\init.prg".
  108.  
  109. cd d:\foo
  110.     Change the current drive and directory. This isn't terribly
  111.     useful, unless your initial program (see above) expects to run
  112.     with some particular directory as the current one.
  113.  
  114. sln d:\foo\bar u:\baz
  115.     Create a symbolic link called "u:\baz" for the file (or directory)
  116.     d:\foo\bar. Only drive u: supports symbolic links, so the second
  117.     name *must* be on drive u:; the first name can be anything.
  118.     A symbolic link is just an alias or nickname for a file; if the
  119.     sample line is included in your mint.cnf file, then references
  120.     to u:\baz are automatically translated by the kernel so that
  121.     they "really" refer to d:\foo\bar. If d:\foo\bar is actually
  122.     a subdirectory, with the file "frob.txt" in it, then that
  123.     file can be accessed either through the name "d:\foo\bar\frob.txt"
  124.     or "u:\baz\frob.txt".
  125.  
  126.     Symbolic links are often used to tell programs where to look for
  127.     files; in this respect they're somewhat like environment variables.
  128.     Some "standard" links are:
  129.         u:\bin        directory to find programs in
  130.         u:\etc        directory to find certain general
  131.                 configuration files (e.g. passwd and termcap)
  132.         u:\local    directory to find node-specific files in
  133.                 (for networked systems)
  134.         u:\lib        directory to find C libraries in
  135.         u:\include    directory to find C header files in
  136.     You can use whatever of these are convenient, or add some others
  137.     of your own.
  138.  
  139. ren d:\nm1 d:\nm2
  140.     Rename a file or directory. This is useful mainly on the pseudo-drive
  141.     v:, which refers to devices. For example, the RS232 port on the ST
  142.     is called "v:\modem1". Earlier versions of MiNT called this
  143.     "v:\rs232", so if your programs care about this you might want
  144.     to put "ren v:\modem1 v:\rs232" to maintain compatibility.
  145.     Similarly, if your software has been ported from Unix and expects
  146.     terminals to be called "tty*", then you might want to put
  147.     "ren v:\modem1 v:\tty1" instead.
  148.  
  149.  
  150. Pseudo Drives
  151.  
  152. MiNT provides some fake "disk drives"; if the contents of these drives
  153. are listed, various "files" are shown. These "files" are not necessarily
  154. real files, but may represent other objects such as executing programs or
  155. regions of memory.
  156.  
  157. The following drives are available:
  158.  
  159. Drive Q:: contains files which are FIFO queues (e.g. pipes). All files
  160. created on drive Q are temporary; when the last program using a FIFO
  161. closes it, it is erased. Normally, drive Q will be empty, but it will
  162. have items on it when you're running a window manager, print spooler,
  163. or similar program that uses FIFOs or pseudo-ttys for communication.
  164.  
  165. Drive V:: contains files which correspond to the BIOS devices; this allows
  166. you to access these devices from within programs. For example, saving an
  167. ASCII text file to "V:\PRN" should cause it to be printed on your printer.
  168. Of course, this will work *only* with ASCII data, so don't expect to get
  169. anything meaningful printed if you try to save your spreadsheet to "V:\PRN"!
  170. The following devices are available:
  171.    CENTR: the centronics printer port
  172.    RS232: the RS232 serial port
  173.    MDI: midi port
  174.    KBD: intelligent keyboard controller
  175.    PRN: printer device (not necessarily the real printer if redirected)
  176.    AUX: auxiliary terminal (usually, but not always, the rs232 port)
  177.    CON: current control terminal (NOT necessarily the keyboard/screen!)
  178.    TTY: same as above
  179.    STDIN: current file handle 0 (standard input)
  180.    STDOUT: current file handle 1 (standard output)
  181.    STDERR: current file handle 2 (standard error)
  182.    CONSOLE: (physical console) the keyboard/screen
  183.    MOUSE: the mouse
  184.    NULL: a null device (like Unix's /dev/null)
  185.  
  186. The "STD*" file handles are useful for providing I/O redirection to programs
  187. that normally require file names on the command line; for example, if you
  188. want to run such a program in a pipeline.
  189.  
  190. Drive X:: listing this drive gives information about currently executing
  191. processes, such as whether they're running, ready, or waiting, their process
  192. i.d. numbers, and the amount of memory they've taken. Deleting one of the
  193. "files" kills the corresponding process. (Killing MiNT is impossible;
  194. killing GEM is a very bad idea). The "files" will have names like "INIT.001";
  195. this means that the process name is "INIT" (presumably because it was started
  196. from a file like "INIT.PRG"), and its process i.d. is 1. You can rename
  197. processes just as if they were files, except that any extension you give is
  198. always replaced with the process i.d. (e.g. if you rename INIT.001 to FOO.BAR,
  199. it will really become FOO.001). The size of a process is the amount of memory
  200. that is allocated to it. Its date/time stamp reflects how much processor
  201. time it has consumed; for example, a process that has consumed 27 hours,
  202. 13 minutes, and 6 seconds of computer time will have a date of Jan.2, 1980
  203. and a time of 03:13:06 (because of the way GEMDOS stores dates, the "0"
  204. point is midnight, Jan. 1, 1980). A process' current state is reflected
  205. by its attribute bits; most of these are not visible from the desktop, alas,
  206. but here are the combinations and their meanings:
  207.     attribute      process state
  208.       0x00        currently running
  209.       0x01        ready to run
  210.       0x20        waiting for an event (e.g. for a child to finish)
  211.       0x21        waiting for I/O
  212.       0x22        zombie (exited, but parent doesn't know yet)
  213.       0x02        terminated and resident
  214.       0x24        stopped by a signal
  215. Deleting a "file" on drive X: will send a SIGTERM signal to the corresponding
  216. process, which will usually result in that process being terminated. It
  217. is not possible to delete processes which are terminated and resident,
  218. or zombie processes.
  219.  
  220. Drive U:: a "unified" file system; all the other drives are visible
  221. on this device. For example, the file C:\FOO can also be referred to
  222. as U:\DRVC\FOO, and X:\INIT.001 is the same as U:\PROC\INIT.001. The
  223. subdirectories "PIPE", "DEV", and "PROC" respectively on drive U:
  224. refer to drives Q:, V:, and X:. The use of the directories on drive U:
  225. instead of these drives is preferred; future versions of MiNT may change
  226. or do away with drives Q:, V:, and X:, but the drive U: subdirectories will
  227. always work.
  228.  
  229. Note that the TOS 1.0 desktop won't recognize drives above P. Other versions
  230. of TOS will, though, so you can use the Install Drive menu selection to
  231. install the pseudo drives so that the desktop can recognize them.
  232.  
  233.  
  234. File Handles and Devices
  235.  
  236. File handle -1 refers to the current control terminal, NOT necessarily
  237. the console (this is where it points by default). BIOS handle 2 also
  238. refers to the control terminal, so that e.g. Bconout(2, c) outputs
  239. a character to the control terminal. Thus,
  240.     Fforce(-1, Fopen("V:\RS232", 3));
  241.     r = Bconin(2);
  242. reads a character from the RS232 port under MiNT. This is done so that
  243. programs that use the BIOS for I/O will be able to run in windows or
  244. over the modem. Similarly, the DOS device CON: refers to the current
  245. control terminal, so Fopen("CON:", 3) is normally equivalent to Fdup(-1).
  246. To access the physical console, use device V:\CONSOLE.
  247.  
  248. In a similar fashion, file handle -2 and bios device 1 (DOS device AUX:)
  249. may be redirected away from the RS232 port (device V:\RS232), and
  250. file handle -3 and bios device 0 (DOS device PRN:) may be directed away
  251. from the Centronics printer port (device V:\CENTR). Since both the DOS
  252. handles and BIOS device numbers are redirected, any program at all will
  253. obey the redirection unless it accesses the hardware directly (or unless
  254. it was written for MiNT and specifically uses the new device names
  255. like V:\CENTR; this should be done only if *absolutely* necessary!).
  256.  
  257. File handles -4 and -5 are new with MiNT, and refer to the MIDI input
  258. and output devices respectively. Redirecting these handles will affect
  259. BIOS operations on bios device 4 (the MIDI port).
  260.  
  261.  
  262. Background Processes
  263.  
  264. (Note that the programs bg.ttp and pipe.ttp, along with some other
  265. sample MiNT utilities, are found in a separate file called
  266. "mntutl.zoo").
  267.  
  268. Programs may be started in the background. A sample program ("bg.ttp")
  269. is provided that will do this for you. It works best from a shell;
  270. for example, to make foo.ttp in the background from gulam, type:
  271.     cd \foo\src
  272.     bg.ttp -o make.out make foo.ttp
  273. The "-o make.out" tells "bg" to redirect the command's standard tty,
  274. output, and error output (handles -1, 1, and 2) to "make.out".
  275. You might also want to redirect the standard input from an empty
  276. file, or from a file that will never have input waiting (like V:\NUL)
  277. so that "make" won't try to read anything from your console.
  278.  
  279. Shells designed to work with MiNT (for example, the "init.prg" that is
  280. provided) may use the Unix "&" notation for running processes in the
  281. background; with this notation, the job above would be:
  282.     cd \foo\src
  283.     make foo.ttp >make.out &
  284. (here the ">make.out" is the notation for redirecting the standard output
  285. of a process). Note that the sample shell does not provide a way of
  286. redirecting the standard error output; however, it does provide job
  287. control (see below), and processes that try to write on the terminal
  288. will be stopped automatically.
  289.  
  290. Only one GEM program can be active ("ready") at a time. This essentially
  291. means that GEM programs cannot be run in the background. It wouldn't
  292. make much sense, anyways, since GEM programs take over the whole screen.
  293.  
  294.  
  295. Pipes
  296.  
  297. Pipes are special files that are used to communicate between processes. The
  298. data in a pipe is always in memory, so using a pipe instead of a temporary
  299. file is usually faster; it also doesn't consume disk space. Only 2048 bytes
  300. can be held in a pipe at once; when a process tries to write more data,
  301. it is suspended until another process reads some data, thus "emptying"
  302. the pipe. If there are no more readers, a process writing on a pipe is
  303. terminated.
  304.  
  305. A simple "pipe" program is provided to run two programs concurrently,
  306. passing data between them in a pipe. The syntax is
  307.     pipe.ttp cmd1 cmd2
  308. which is equivalent to the Unix "cmd1 | cmd2". Note that if cmd1 or cmd2
  309. contain arguments, then you must run the "pipe" program from a shell that
  310. supports the Atari standard extended argument convention, and that you
  311. must enclose the commands in quotes, e.g. in gulam:
  312.     set env_style mw    # extended arguments
  313.     pipe 'ls.ttp -l foo' 'fgrep.ttp myfile'
  314. does the same as the Unix command
  315.     ls -l foo | fgrep myfile
  316. or using a temporary file
  317.     ls -l foo >junk; fgrep myfile <junk; rm junk
  318.  
  319. Shells designed to work explicitly with MiNT will probably not need the
  320. external "pipe" command, and instead will use the Unix notation for
  321. pipelines. (The sample shell that comes with MiNT as init.prg does
  322. this). This second method is preferable, as it provides a way of
  323. joining more than two programs in a pipeline.
  324.  
  325.  
  326. Job Control
  327.  
  328. MiNT currently (as of version 0.6) supports job control. The ^Z
  329. (control-Z) key can be used to suspend a process. The process can
  330. be restarted again if it is sent the appropriate signal. A sample
  331. program (fg.ttp) is provided that will do this; the syntax is 
  332.     fg.ttp process-name
  333. where "process-name" is either the process id of the process, or its
  334. name as displayed in the drive X: listing (e.g. gem.003). If the process
  335. was not stopped, an error will occur.
  336. There is also a "delayed" suspend key, ^Y, that takes effect only when
  337. a process attempts to read it.
  338.  
  339. Some programs written for TOS put the terminal in "raw" mode, where no
  340. control characters are interpreted. You can use CTRL-ALT-Z to achieve
  341. the effect of ^Z for such programs. However, this feature should be used
  342. with caution -- it's possible that the TOS program had a good reason
  343. for not wanting to be interrupted!
  344.  
  345. More sophisticated job control facilites can be provided by shells that
  346. are specifically written with MiNT in mind. The sample "init.prg"
  347. demonstrates this. Jobs run in the background from such shells are auto-
  348. matically stopped when they attempt to read from the terminal or write to it.
  349. Thus, you can run a long compile in the background, and if an error
  350. occurs and the compiler attempts to write on the screen, it will be stopped.
  351.  
  352.  
  353. Programming with MiNT
  354.  
  355. A file (mintbind.h) is provided that gives a C interface to the new
  356. MiNT system calls. Users of other programming languages will have to write
  357. the interfaces themselves; it should be relatively straightforward, as long
  358. as your compiler provides a way to call GEMDOS directly.
  359.  
  360. Testing for the presence of MiNT:
  361.  
  362. There are several ways to check to see if MiNT is active. Probably the best
  363. way is to check the cookie jar; MiNT installs a cookie of
  364. 0x4d694e54 (in ASCII, 'MiNT'), with a value consisting of the major/
  365. minor version numbers in the high/low bytes of the low word. Thus, MiNT
  366. version 1.2 will have a cookie value of 0x00000102L. (This isn't
  367. the place to explain the cookie jar, but basically it's a list of
  368. (cookie, value) pairs of longwords, terminated by cookie 0; a pointer
  369. to the jar is found at 0x5a0. MiNT always installs a cookie jar; versions
  370. of TOS prior to 1.6 don't always, in which case 0x5a0 will contain 0).
  371.  
  372. A "quick and dirty" way to see if MiNT is active is to make a system
  373. call that only exists under MiNT (preferably one with no side effects!).
  374. Pgetpid() or Syield() are good choices. If MiNT is not active, these
  375. calls will fail, returning -32 (invalid function). This method has the
  376. disadvantage that future versions of TOS, or other multitasking programs,
  377. may use the same trap numbers as MiNT, but have different meanings.
  378. For this reason, the "cookie jar" method is preferred.
  379.  
  380. Interprocess Communication:
  381.  
  382. MiNT provides 4 forms of interprocess communication (IPC): signals, fifos,
  383. shared memory, and message passing.
  384.  
  385. Signals:
  386.  
  387. Signals are a way of notifying a process of an event. The Pkill(pid, sig)
  388. system call is used to send signal number "sig" to the process with process
  389. id "pid". It is called "Pkill" because the default action of most signals is
  390. to terminate the process. If a process wishes to catch a signal and do
  391. processing, it can use the Psignal(sig, func) system call to arrange to have
  392. function "func" called when signal "sig" is received. If func is 0, then
  393. the default action is restored. If func is 1, then the signal will be ignored.
  394.  
  395. Processes can temporarily block receipt of signals via the Psigblock() and
  396. Psigsetmask() system calls.
  397.  
  398. See the file "signal.doc" in the MiNT Programmer's Guide for a more complete
  399. explanation of signals.
  400.  
  401. Fifos:
  402.  
  403. Fifos are "first in first out" message queues. Pipes are a special kind of
  404. (unidirectional) fifo. Fifos are represented by files in the subdirectory
  405. "PIPE" on drive "U:". They are created with the Fcreate(name, flags)
  406. system call. "name" will be the name under which the fifo is known
  407. (maximum 13 characters); "flags" is explained below. The returned file handle
  408. is treated just like an ordinary file, and may be written to and read from
  409. (unless the fifo is unidirectional, in which case it may only be written to).
  410. The program that creates the fifo is normally called the "server". Other
  411. programs ("clients") may use the Fopen(name, mode) system call to open the
  412. other end of the fifo and read the data that the server writes, or write data
  413. for the server to read. When the last program (either client or server) using
  414. a fifo closes it, the fifo is deleted automatically. Note that one program can
  415. be both client and server, if it creates a fifo with Fcreate and then opens it
  416. again with Fopen. Also, children of the server can inherit the Fcreate'd file
  417. handle and thus have access to the "server" side of the fifo.
  418.  
  419. The bits in the "flags" argument to Fcreate have the following meanings:
  420. 0x01: make fifo unidirectional (server can write, clients can read)
  421. 0x02: cause reads to return EOF if no other processes are writing, and writes
  422.       to raise the SIGPIPE signal if no other processes are reading. The
  423.       default action (if this flag is not given) is to block waiting for
  424.       reads and writes
  425. 0x04: make the fifo a pseudo-tty; to client processes, the fifo will act
  426.       just like a terminal with the server "typing" the characters; for
  427.       example, if the server writes a ^C, SIGINT will be sent to clients
  428.  
  429. Attempting to Fcreate() a fifo with the same name as an already existing
  430. one will result in an access error (i.e. the Fcreate will fail).
  431.  
  432. Pipes may be created through the Fpipe() system call as well as through
  433. the Fcreate/Fopen pair; the former method is easier, since the kernel
  434. takes care of name conflicts, etc.
  435.  
  436. Fifos may be locked by processes via the Fcntl system call, as follows:
  437.  
  438. struct flock {
  439.     short l_type;        /* type of lock */
  440. #define F_RDLCK        0
  441. #define F_WRLCK        1
  442. #define F_UNLCK        3
  443.     short l_whence;        /* what is the lock relative to? */
  444.         /* 0 == start of file, 1 == current pos. in file, 2 == EOF */
  445.     long l_start;        /* start of locked region */
  446.     long l_len;        /* 0 for rest of file */
  447.     short l_pid;        /* set by F_GETLK */
  448. };
  449.  
  450. Fcntl(fd, &lock, F_SETLK): set a lock as specified by the lock structure.
  451. The current version of MiNT only understands locks on the whole FIFO,
  452. so lock.l_start and lock.l_len should both be 0. If lock.l_type is F_UNLCK,
  453. then the lock is released. Otherwise, the file whole file is locked
  454. (future versions of MiNT may distinguish between read and write locks,
  455. but for now all locks are treated as write locks (F_WRLCK) and block both
  456. reads and writes). If another process has locked the fifo, returns -36
  457. (access denied). If a process holding a lock terminates, the fifo is
  458. automatically unlocked.
  459.  
  460. Fcntl(fd, &lock, F_GETLK): if a lock exists on the fifo, set lock to
  461. indicate what kind of lock it is; otherwise, set lock.l_type to F_UNLCK.
  462.  
  463. Locks are only "advisory"; that is, programs may ignore locks if they
  464. choose to do so. However, they are a good way to insure that two clients'
  465. data are not mixed together in a fifo.
  466.  
  467. See the sample LPR and LPD utilites for a demonstration of how to use fifos.
  468.  
  469. Shared memory:
  470.  
  471. Children created with the Pexec(4,...) or with Pexec(104,...) share all of
  472. their parent's memory, as do children created with the Pvfork() system call.
  473. Hence, they may communicate with their parent (or with each other) via
  474. global variables.
  475.  
  476. Rendezvous:
  477.  
  478. The Pmsg() system call provides a simple message based form of IPC. See
  479. the manual page for Pmsg in the MiNT Programmer's Guide for further details.
  480.  
  481.  
  482. MiNT extensions to GEMDOS calls:
  483.  
  484. Fsfirst/Fsnext:
  485.     MiNT domain processes (see the Pdomain()) system call below) get
  486. lower case filenames from Fsfirst/Fsnext on a TOS filesystem. This is
  487. because most programs end up converting them to lowercase anyways, to
  488. be more Unix-like. *Please* don't do this translation yourself, let
  489. MiNT handle it -- some filesystems (e.g. the minix one) are case
  490. sensitive! If you really, truly, prefer uppercase filenames, run in
  491. the TOS domain.
  492.  
  493. Pexec(100, name, cmdline, environment):
  494.     Similar to Pexec(0, ...), except the calling program does not wait for
  495. the child to finish. Returns a negative error code, or the (positive)
  496. process I.D. of the child.
  497.  
  498. Pexec(104, name, basepage, 0L):
  499.     Similar to Pexec(4, ...); starts executing a basepage previously
  500. set up by Pexec mode 3, 5, or 7. The caller does not wait for
  501. the child to finish. Returns a negative error code, or the process I.D.
  502. of the child. Note that the child's environment and basepage are
  503. owned by both the child and the parent. "name" is a pointer to a string
  504. to be used to supply a name for the new process; if it is NULL, then
  505. the parent's name is used.
  506.  
  507. Pexec(106, name, basepage, 0L):
  508.     Similar to Pexec(104,...) except that the child's environment and
  509. basepage are *not* owned by the parent.
  510.  
  511. Pexec(200, name, cmdline, environment):
  512.     As with Pexec(0,...) and Pexec(100,...) this runs a program. However,
  513. with this variant the caller is completely replaced with the executing
  514. program. The process retains its process i.d. and most other attributes,
  515. but all of its memory is freed and a new address space is set up for it
  516. containing the code from the indicated program. Whereas Pexec(0,...)
  517. is like a subroutine call, Pexec(200,...) is like a "goto". It returns
  518. only if an error occurs.
  519.  
  520.  
  521. New MiNT calls:
  522.  
  523. See the manual pages in the MiNT Programmer's Guide for descriptions of
  524. these calls. (The MiNT Programmer's Guide is available separately in
  525. the file mintdoc.zoo).
  526.  
  527. word Syield():                    [ GEMDOS 0xff ]
  528. word Fpipe( word *ptr ):            [ GEMDOS 0x100 ]
  529. word Fcntl( word f, long arg, word cmd):    [ GEMDOS 0x104 ]
  530. long Finstat( word f ):                [ GEMDOS 0x105 ]
  531. long Foutstat( word f )                [ GEMDOS 0x106 ]
  532. long Fgetchar(word f, word mode):        [ GEMDOS 0x107 ]
  533. long Fputchar( word f, long c, word mode ):    [ GEMDOS 0x108 ]
  534. long Pwait():                    [ GEMDOS 0x109 ]
  535. word Pnice( word delta ):            [ GEMDOS 0x10a ]
  536. word Pgetpid():                    [ GEMDOS 0x10b ]
  537. word Pgetppid():                [ GEMDOS 0x10c ]
  538. word Pgetpgrp():                [ GEMDOS 0x10d ]
  539. word Psetpgrp(pid, newgrp):            [ GEMDOS 0x10e ]
  540. word Pgetuid():                    [ GEMDOS 0x10f ]
  541. word Psetuid( word id ):            [ GEMDOS 0x110 ]
  542. word Pkill( word pid, word sig ):        [ GEMDOS 0x111 ]
  543. long Psignal(word sig, long handler):        [ GEMDOS 0x112 ]
  544. word Pvfork():                    [ GEMDOS 0x113 ]
  545. word Pgetgid():                    [ GEMDOS 0x114 ]
  546. word Psetgid(word id):                [ GEMDOS 0x115 ]
  547. long Psigblock(long mask):            [ GEMDOS 0x116 ]
  548. long Psigsetmask(long mask):            [ GEMDOS 0x117 ]
  549. long Pusrval(long arg):                [ GEMDOS 0x118 ]
  550. word Pdomain(word newdom):            [ GEMDOS 0x119 ]
  551. void Psigreturn():                [ GEMDOS 0x11a ]
  552. long Pfork():                    [ GEMDOS 0x11b ]
  553. long Pwait3(word flag, long *rusage):        [ GEMDOS 0x11c ]
  554. word Fselect(word timeout, long *rfds, long *wfds, long *xfds):
  555.                         [ GEMDOS 0x11d ]
  556. void Prusage( long r[8] ):            [ GEMDOS 0x11e ]
  557. long Psetlimit(word lim, long value):        [ GEMDOS 0x11f ]
  558. long Talarm( long secs ):            [ GEMDOS 0x120 ]
  559. void Pause():                    [ GEMDOS 0x121 ]
  560. long Sysconf( word n ):                [ GEMDOS 0x122 ]
  561. long Psigpending()                [ GEMDOS 0x123 ]
  562. long Dpathconf( char *name, word n ):        [ GEMDOS 0x124 ]
  563. long Pmsg( word mode, long mbox, void *msg ):    [ GEMDOS 0x125 ]
  564. long Fmidipipe( word pid, word in, word out ):    [ GEMDOS 0x126 ]
  565. word Prenice( word pid, word delta ):        [ GEMDOS 0x127 ]
  566. long Dopendir( char *name, word flag ):        [ GEMDOS 0x128 ]
  567. long Dreaddir( word buflen, long dir, char *buf):[GEMDOS 0x129 ]
  568. long Drewinddir( long dir ):            [ GEMDOS 0x12a ]
  569. long Dclosedir( long dir ):            [ GEMDOS 0x12b ]
  570. long Fxattr( word flag, char *name, void *buf ):[ GEMDOS 0x12c ]
  571. long Flink( char *oldname, char *newname ):    [ GEMDOS 0x12d ]
  572. long Fsymlink( char *oldname, char *newname ):    [ GEMDOS 0x12e ]
  573. long Freadlink( word siz, char *buf, char *name):[GEMDOS 0x12f ]
  574. long Dcntl( word cmd, char *name, long arg ):    [ GEMDOS 0x130 ]
  575. long Fchown( char *name, word uid, word gid):    [ GEMDOS 0x131 ]
  576. long Fchmod( char *name, word mode ):        [ GEMDOS 0x132 ]
  577.